Эта страница переведена с помощью Cloud Translation API.

Срок действия платежной транзакции

Узнайте, как продавцы интегрируют платежные приложения и как работают платежные транзакции с API-интерфейсом запроса платежей.

Eiji Kitamura

Milica Mihajlija

API веб-платежей — это специальные платежные функции, впервые встроенные в браузер. Благодаря веб-платежам интеграция торговцев с платежными приложениями становится проще, а опыт клиентов — более рационализированным и безопасным.

Чтобы узнать больше о преимуществах использования веб-платежей, ознакомьтесь с разделом Расширение возможностей платежных приложений с помощью веб-платежей .

В этой статье описывается процедура совершения платежа на сайте продавца и объясняется, как работает интеграция с платежным приложением.

Процесс состоит из 6 этапов:

Торговец инициирует платежную транзакцию.
Продавец показывает кнопку оплаты.
Клиент нажимает кнопку оплаты.
Браузер запускает платежное приложение.
Если клиент меняет какие-либо данные (например, варианты доставки или адрес), продавец обновляет данные транзакции, отражая изменения.
После того, как покупатель подтвердит покупку, продавец проверит платеж и завершит транзакцию.

Шаг 1: Торговец инициирует платежную транзакцию.

Когда клиент решает совершить покупку, продавец инициирует платежную транзакцию, создавая объект PaymentRequest . Этот объект включает важную информацию о транзакции:

Допустимые способы оплаты и их данные для обработки транзакции.
Подробная информация, такая как общая стоимость (обязательно) и информация о товарах.
Варианты, с помощью которых продавцы могут запрашивать информацию о доставке, такую как адрес доставки и вариант доставки.
Торговцы также могут запросить адрес выставления счета, имя плательщика, адрес электронной почты и номер телефона.
Торговцы также могут включать необязательный тип доставки ( shipping , delivery или pickup ) в PaymentRequest . Платежное приложение может использовать это как подсказку для отображения правильных меток в своем пользовательском интерфейсе.

const request = new PaymentRequest([{
  supportedMethods: 'https://bobpay.xyz/pay',
  data: {
    transactionId: '****'
  }
}], {
  displayItems: [{
    label: 'Anvil L/S Crew Neck - Grey M x1',
    amount: { currency: 'USD', value: '22.15' }
  }],
  total: {
    label: 'Total due',
    amount: { currency: 'USD', value : '22.15' }
  }
}, {
  requestShipping: true,
  requestBillingAddress: true,
  requestPayerEmail: true,
  requestPayerPhone: true,
  requestPayerName: true,
  shippingType: 'delivery'
});

Включая идентификатор транзакции

Некоторые обработчики платежей могут потребовать от продавца предоставить идентификатор транзакции, который они выдали заранее как часть информации о транзакции. Типичная интеграция включает связь между продавцом и сервером обработчика платежей для резервирования общей цены. Это не позволяет недобросовестным клиентам манипулировать ценой и обманывать продавца с помощью проверки в конце транзакции.

Торговец может передать идентификатор транзакции как часть свойства data объекта PaymentMethodData .

При наличии информации о транзакции браузер проходит процесс обнаружения платежных приложений, указанных в PaymentRequest , на основе идентификаторов платежных методов. Таким образом, браузер может определить платежное приложение для запуска, как только продавец будет готов продолжить транзакцию.

Чтобы подробно узнать, как работает процесс обнаружения, ознакомьтесь с разделом Настройка способа оплаты .

Шаг 2: Продавец показывает кнопку оплаты

Торговцы могут поддерживать множество способов оплаты, но должны отображать кнопки оплаты только для тех, которые клиент может использовать. Отображение кнопки оплаты, которая не может использоваться, является плохим пользовательским опытом. Если торговец может предсказать, что способ оплаты, указанный в объекте PaymentRequest , не будет работать для клиента, он может предоставить запасное решение или вообще не отображать эту кнопку.

Используя экземпляр PaymentRequest , продавец может запросить, доступно ли у клиента платежное приложение.

Доступно ли клиенту платежное приложение?

Метод canMakePayment() PaymentRequest возвращает true если платежное приложение доступно на устройстве клиента. «Доступно» означает, что обнаружено платежное приложение, поддерживающее способ оплаты, и что установлено платежное приложение для конкретной платформы или веб-платежное приложение готово к регистрации .

const canMakePayment = await request.canMakePayment();
if (!canMakePayment) {
  // Fallback to other means of payment or hide the button.
}

Шаг 3: Клиент нажимает кнопку оплаты.

Когда покупатель нажимает кнопку оплаты, продавец вызывает метод show() экземпляра PaymentRequest , который немедленно запускает платежный пользовательский интерфейс.

Если окончательная общая стоимость устанавливается динамически (например, извлекается с сервера), продавец может отложить запуск платежного интерфейса до тех пор, пока не станет известна общая стоимость.

Отсрочка запуска платежного интерфейса

Ознакомьтесь с демонстрацией отсрочки платежного интерфейса до тех пор, пока не будет определена окончательная общая стоимость.

Чтобы отложить платежный пользовательский интерфейс, продавец передает обещание методу show() . Браузер будет отображать индикатор загрузки до тех пор, пока обещание не будет выполнено и транзакция не будет готова к началу.

const getTotalAmount = async () => {
  // Fetch the total amount from the server, etc.
};

try {
  const result = await request.show(getTotalAmount());
  // Process the result…
} catch(e) {
  handleError(e);
}

Если в качестве аргумента для show() не указано обещание, браузер немедленно запустит платежный пользовательский интерфейс.

Шаг 4: Браузер запускает платежное приложение.

Браузер может запустить платежное приложение, привязанное к конкретной платформе, или веб-приложение для оплаты. (Вы можете узнать больше о том , как Chrome определяет, какое платежное приложение запустить .)

То, как будет построено платежное приложение, по большей части зависит от разработчика, но события, отправляемые от продавца и к нему, а также структура данных, передаваемых вместе с этими событиями, стандартизированы.

При запуске платежного приложения оно получает информацию о транзакции, переданную объекту PaymentRequest на шаге 1, которая включает в себя следующее:

Данные о способе оплаты
Общая стоимость
Варианты оплаты

Платежное приложение использует информацию о транзакции для маркировки своего пользовательского интерфейса.

Шаг 5: Как продавец может обновить данные транзакции в зависимости от действий покупателя

Клиенты имеют возможность изменить детали транзакции, такие как способ оплаты и вариант доставки в платежном приложении. Пока клиент вносит изменения, продавец получает события изменения и обновляет детали транзакции.

Торговец может получить четыре типа событий:

Событие изменения способа оплаты
Событие изменения адреса доставки
Событие изменения варианта доставки
Событие проверки продавца

Событие изменения способа оплаты

Платежное приложение может поддерживать несколько способов оплаты, а продавец может предлагать специальную скидку в зависимости от выбора покупателя. Чтобы охватить этот вариант использования, событие изменения способа оплаты может информировать продавца о новом способе оплаты, чтобы он мог обновить общую цену со скидкой и вернуть ее обратно в платежное приложение.

request.addEventListener('paymentmethodchange', e => {
  e.updateWith({
    // Add discount etc.
  });
});

Событие изменения адреса доставки

Платежное приложение может опционально предоставлять адрес доставки клиента. Это удобно для клиентов, поскольку им не нужно вручную вводить какие-либо данные в форму, и они могут хранить свой адрес доставки в своих предпочтительных платежных приложениях, а не на нескольких разных веб-сайтах продавцов.

Если клиент обновит свой адрес доставки в платежном приложении после инициирования транзакции, продавцу будет отправлено событие 'shippingaddresschange' . Это событие помогает продавцу определить стоимость доставки на основе нового адреса, обновить общую цену и вернуть ее в платежное приложение.

request.addEventListener('shippingaddresschange', e => {
  e.updateWith({
    // Update the details
  });
});

Если продавец не может осуществить доставку по обновленному адресу, он может предоставить сообщение об ошибке, добавив параметр ошибки к сведениям о транзакции, возвращаемым в платежное приложение.

Событие изменения варианта доставки

Торговец может предложить клиенту несколько вариантов доставки и делегировать этот выбор платежному приложению. Варианты доставки отображаются в виде списка цен и названий услуг, из которых клиент может выбрать. Например:

Стандартная доставка - Бесплатно
Экспресс-доставка - 5 долларов США

Когда клиент обновляет вариант доставки в платежном приложении, продавцу отправляется событие 'shippingoptionchange' . Затем продавец может определить стоимость доставки, обновить общую цену и вернуть ее в платежное приложение.

request.addEventListener('shippingoptionchange', e => {
  e.updateWith({
    // Update the details
  });
});

Торговец также может динамически изменять параметры доставки на основе адреса доставки клиента. Это полезно, когда торговец хочет предложить различные наборы параметров доставки для внутренних и международных клиентов.

Событие проверки продавца

Для дополнительной безопасности платежное приложение может выполнить проверку продавца перед тем, как перейти к платежному потоку. Разработка механизма проверки зависит от платежного приложения, но событие проверки продавца служит для информирования продавца об URL-адресе, который он может использовать для проверки себя.

request.addEventListener('merchantvalidation', e => {
  e.updateWith({
    // Use `e.validateURL` to validate
  });
});

Шаг 6: Торговец проверяет платеж и завершает транзакцию.

Когда клиент успешно авторизует платеж, метод show() возвращает обещание, которое разрешается в PaymentResponse . Объект PaymentResponse включает следующую информацию:

Детали результата платежа
Адрес доставки
Вариант доставки
Контактная информация

На этом этапе в пользовательском интерфейсе браузера может по-прежнему отображаться индикатор загрузки, означающий, что транзакция еще не завершена.

Если платежное приложение завершает работу из-за сбоя или ошибки платежа, обещание, возвращенное функцией show() отклоняется, и браузер завершает платежную транзакцию.

Обработка и проверка платежа

details в PaymentResponse — это объект платежных учетных данных, возвращаемый платежным приложением. Торговец может использовать учетные данные для обработки или проверки платежа. То, как работает этот критический процесс, зависит от обработчика платежей.

Завершение или повторная попытка транзакции

После того, как продавец определит, была ли транзакция успешной или нет, он может:

Вызовите метод .complete() , чтобы завершить транзакцию и закрыть индикатор загрузки.
Позвольте клиенту повторить попытку, вызвав метод retry() .

async function doPaymentRequest() {
  try {
    const request = new PaymentRequest(methodData, details, options);
    const response = await request.show();
    await validateResponse(response);
  } catch (err) {
    // AbortError, SecurityError
    console.error(err);
  }
}

async function validateResponse(response) {
  try {
    const errors = await checkAllValuesAreGood(response);
    if (errors.length) {
      await response.retry(errors);
      return validateResponse(response);
    }
    await response.complete("success");
  } catch (err) {
    // Something went wrong…
    await response.complete("fail");
  }
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();

Следующие шаги

Подробно о том, как объявить идентификатор способа оплаты, читайте в разделе Настройка способа оплаты .
Узнайте, как создать платежное приложение для конкретной платформы, в руководстве разработчика платежных приложений для Android .
Узнайте, как создать приложение для веб-платежей, в Руководстве разработчика приложений для веб-платежей .